Subject: An Alternate Approach to SNA over IP

From: "Shannon Nix" <[email-masked]>
Date: Wed, 22 Sep 93 11:33:48 EST

Hello,

When we at Netlink began thinking about SNA over IP a couple years ago,
we were favoring a different approach from the one this group has undertaken.  

The key difference is:

With DLSW, IBM has chosen to multiplex SNA data links over one or more 
reliable TCP connections.  While we considered this approach, we were favoring 
encapsulating LLC-2 sessions inside of IP datagrams.

Recent consideration some of our DLSW discussion topics:

1) SCALABILITY
2) FLOW-CONTROL

has caused me to reconsider our original design in a more favorable light.

I realize this may not be a great time to propose a fundamental change
in design.  However, it does seem to address a lot of the key issues that
the SIG has been wrestling with.

I will outline (briefly) the scheme below and discuss its pros and cons:

SYSTEM ARCHITECTURE:

+------------------------------------------+
|            DATA LINK PASSTHRU            |
+------------------------------------------+
----- NORMALIZED DATA LINK INTERFACE ------
+------++------++--------------------------+
| SDLC || QLLC ||           LLC-2          |
+------++------++--------------------------+
                +-------++-------++--------+
                | 802.5 || 802.3 || IPSEQ  |
                +-------++-------++--------+
                                  +--------+
                                  |   IP   |
                                  +--------+
                                  
NOTE : The NORMALIZED DATA LINK INTERFACE implies that all DLCs
       present a generic ABM-like appearance.
                                  
NOTE : The DATA LINK PASSTHRU component consists of a state machine
       that "ties together" data link events from any two normalized
       data links and gives them the appearance of a single data link.
       
       This state machine would not be terribly dissimilar from 
       the one in RFC 1434.
                                  
NOTE : The IPSEQ insures that IP frames are delivered in sequence
       between peer LLC-2 stacks.  This might even be UDP???.
       
FRAME FORMAT:

+--------+-----------+---------------+----------------------------+       
| IP HDR | IPSEQ HDR | 802.5 MAC HDR | LLC HDR | DATA             |
+--------+-----------+---------------+----------------------------+       
       
ROUTE EXPLORATION:

1.       CANUREACH will now be triggerred by a broadcast TEST emmitted
         by the MAC service user, the LLC stack.  It could be implemented 
         by using IP multicast.  The multicast group address and the virtual 
         LAN number (for SRB) would be commonly administered throughout a 
         DLSW network.
         
2. While ICANREACHs could be directed to the originator, it might
        be advantageous to multicast those as well.  This would allow other
        stations to "learn".
       
ADVANTAGES OF LLC over IP:

1.  SCALABLE!!.  LLC-2 stacks should be designed to support many stations
    on a LAN.  Since we all have such a stack lets use them!
    
2.  RESOURCE DEFINITION.  Route Exploration is implemented in the same 
    fashion as LAN explorations.  The broadcast is simulated by using
    a multicast address.  In this fashion DLSW do not have to be defined
    to one another.  The only requirement is the administration of the
    multicast group to which the DLSW belongs.
    
3.  ROUTE-DISCOVERY.  Route Resolution (ICANREACH) Data may be multicast 
    rather than directed to allow other DLSW nodes to "learn" IP-MAC 
    correlations.
    
4.  FLOW CONTROL.  LLC-2 stacks have sufficient backpressure mechanisms:
    sliding window, RNR,....  Lets use them!.
    
5.  FRAME SIZE.  IP+ IPSEQ + MAC + LLC + DATA <  IP + TCP + SSP + DATA
               ( X +   2   + 18  +  4  +  Y ) < ( X + 20  + 16  +  Y )
                                   24 + (X+Y) < 36 + (X+Y)
                                   
    A third less filling!                                   
                                   
6.  EASE OF IMPLEMENTATION.  No need to implement convert packets into
    a stream and back again.
    
    Tastes great!
    
7.  END-TO-END LF - Since this is already carried in the RIF let's use it.

8.  END-TO-END RIF - ??? as an option???

DISADVANTAGES (?):

1.  SUPERVISORY TRAFFIC:  S-FRAMES will also travel on the backbone.
    However, I'm not sure a properly tuned LLC endpoint will generate much
    more overhead ( if not less) than the combination of:
      1)  TCP's control mechanisms
      2)  A DLSW pacing mechanism - for flow control
      3)  A Keep-alive mechanism if we choose to have this function

    Also the frame size savings on productive traffic will help to counter-
    balance this as well.

Sorry if I've rocked the boat,
Shannon

(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)

---

From: [email-masked] (John R. Pickens)
Date: Thu, 23 Sep 93 9:34:50 PDT

Adding to comments of others.

I think it comes down to requirements.  If there were a requirement to better 
the characteristics of current generation TCP (easy to improve upon), then
proposals like your LLC2 proposal should be put on the table.  However I
have not seen a DLS group-wide identification of this issue.  So, in the
interest of closing quickly on DLS I would propose staying the course
with TCP.

However, if the issue were to be opened at some future date, why stop
with LLC2 - an old generation windows-based flow control scheme.  Why
not move to a new generation transport, like RTP or XTP (or one or two
good proprietary schemes of which I am aware) - over IP. But that's a 
discussion for another day....

JP
--